-
Notifications
You must be signed in to change notification settings - Fork 7
UIREQ-1313: Display Anonymized Requesters #1336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Jest Unit Test Results 1 files ± 0 68 suites +2 1m 45s ⏱️ +5s Results for commit d9f2eb7. ± Comparison against base commit 37b4890. This pull request removes 9 and adds 20 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
|
@Dmitriy-Litvinenko , @brycekbargar
FYI see these instructions for how to merge the original PR from the fork. GitHub will recognize matching commit hashes across the two PRs, updating the checks on the original PR (where they originally failed due to lack of access to secrets) to reflect the status on the derived PR (where presumably they pass). In the past, we have generally merged the original PR in an effort to best-preserve authorship, though @brycekbargar will be listed here as a co-author. |
zburke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a lot of great work here, but I think it needs a bit of clean-up and documentation before it is ready to merge.
The rock this PR is built on is that undefined user-data represents "unknown" whereas null user-data represents "anonymized". Please document this approach in the PR description, or link to a wiki page or a jira ticket or ... something that describes how anonymized data can be recognized from data that is simply missing or corrupt.
As you noted, display logic related to users/proxies was spread around and duplicated. I like the way you have consolidated it here. Nice job!
| describe('BarcodeLink', () => { | ||
| describe('When barcode is presented', () => { | ||
| let mockedRequester; | ||
| let mockedRequesterId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this never gets reassigned, use const instead of assigning it in the beforeEach.
| }); | ||
|
|
||
| describe('FullNameLink', () => { | ||
| let mockedRequesterId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this never gets reassigned, use const instead of assigning it in the beforeEach.
| userId, | ||
| user, | ||
| }) => { | ||
| if (user != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conditionals are safer when they are shaped like "if (things I need) { stuff() } else { error-or-default }". Here, that means if (user).
| return userId != null | ||
| ? <FormattedMessage id="ui-requests.errors.user.unknown" /> | ||
| : <FormattedMessage id="ui-requests.requestMeta.anonymized" />; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, be inclusive not exclusive. I would expect Sonar to complain here. It prefers positive conditions where there is an else. IOW, "if (condition) { thing } else { default }" is better than "if (not condition) { default } else { thing }".
Also, use strict comparisons (=== or !==) instead of abstract operators (== or !=) to avoid unexpected type conversions. Include a comment when you are distinguishing among different kinds of falsey values. null vs undefined is a subtle difference, so any help you can give to somebody debugging this code in the future is helpful.
Here, null means anonymized and undefined means unknown. Just say that :) In fact, consider putting it in a header-comment up before line 8 that describes how this component treats all the different props it can receive.
| @@ -1 +1 @@ | |||
| import React from 'react'; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need to import React itself; we're on React v18.2 and this import has been automatically included since v17. There's no harm, but in new code you might as well omit it.
The assumptions have been added to the UIREQ-1313 JIRA ticket as well as the https://folio-org.atlassian.net/wiki/spaces/DD/pages/1056210996/Request+anonymization technical design. |
|
Hello. @brycekbargar Thank you for your pull request. We left several comment on them. Could you please take a look on them when you will have time? |
|
Hello. @folio-org/fe-tl-reviewers Could you please take a look when you will have time? |
* Split RequesterLinks tests into two files * Replace let with const in test code * Remove unneeded react imports * Remove explicitly checking for null in FullNameLink
4756164 to
d9f2eb7
Compare
|
| </Row> | ||
| ); | ||
| export function isUserAnonymized(userId) { | ||
| return !userId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please check here for equal to null?
return userId === null;
just for example we also can add
/**
* Checks if the user is anonymized.
* A user is considered anonymized if the userId is null.
*
* @param {*} userId - The user identifier to check.
* @returns {boolean} True if userId is null, otherwise false.
*/
describe('isUserAnonymized', () => {
it('should returns true when userId is null', () => {
expect(isUserAnonymized(null)).toBe(true);
});
it('should returns false when userId is a string', () => {
expect(isUserAnonymized('abc123')).toBe(false);
});
it('should returns false when userId is undefined', () => {
expect(isUserAnonymized(undefined)).toBe(false);
});
it('should returns false when userId is a number', () => {
expect(isUserAnonymized(123)).toBe(false);
});
it('should returns false when userId is an empty string', () => {
expect(isUserAnonymized('')).toBe(false);
});
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason to check for null specifically instead of both null and undefined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello, as far as I understand from the description and explanations, for "anonymous" users, the "id" will only be changed to "null."
The case where the user's "id" is "undefined" does not apply to "anonymous" users.
|
Duplicate for #1348 |



Purpose
We're in the process of anonymizing requests, like how loans have been. Previously if user data was not returned for a request it was caused by something weird but now it indicates the request has been anonymized (probably).
Approach
There were many disparate places that were handling the display and logic around requesters. I consolidated all the ways to create a link to a user/barcode into a component as well as all the ways to display the requester/proxy. Once these were all consistent I changed the text/link behavior for when a user does not exist to Anonymized. I'm going to be updating the request list in another PR to better display anonymized requests which will now be a easier because of the consistency.
I'm not super happy with the amount of duplication with the React PropTypes but I'm not a React developer and don't know how this is usually deduplicated.
Refs
https://folio-org.atlassian.net/browse/UIREQ-1313
Corresponding Backend PR: folio-org/mod-circulation#1623
Screenshots
To test this I nulled out the requester in the database.
Pre-Merge Checklist
Before merging this PR, please go through the following list and take appropriate actions.
If there are breaking changes, please STOP and consider the following:
Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.
While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.
Notes:
Origin pull request was #1330 but we was not able run Sonar for fork and we created current pull.